Date: Tue, 14 Jun 94 04:30:13 PDT
From: Ham-Digital Mailing List and Newsgroup <ham-digital@ucsd.edu>
Errors-To: Ham-Digital-Errors@UCSD.Edu
Reply-To: Ham-Digital@UCSD.Edu
Precedence: Bulk
Subject: Ham-Digital Digest V94 #194
To: Ham-Digital


Ham-Digital Digest          Tue, 14 Jun 94       Volume 94 : Issue  194

Today's Topics:
             An open note to Gary Coffman, KE4ZV (6 msgs)
                     Need info on Ottawa PI Card
                        Packet Ideas Sought...
                   Thenet Eprom 1X for Thenet Node
                TM-733A and 9600 baud packet (3 msgs)

Send Replies or notes for publication to: <Ham-Digital@UCSD.Edu>
Send subscription requests to: <Ham-Digital-REQUEST@UCSD.Edu>
Problems you can't solve otherwise to brian@ucsd.edu.

Archives of past issues of the Ham-Digital Digest are available 
(by FTP only) from UCSD.Edu in directory "mailarchives/ham-digital".

We trust that readers are intelligent enough to realize that all text
herein consists of personal comments and does not represent the official
policies or positions of any party.  Your mileage may vary.  So there.
----------------------------------------------------------------------

Date: Mon, 13 Jun 94 08:07:56 EDT
From: world!mv!lmr!rapp@uunet.uu.net
Subject: An open note to Gary Coffman, KE4ZV
To: ham-digital@ucsd.edu

Erich Franz Stocker <stocker@spsosun.gsfc.nasa.gov> writes:

... stuff deleted
( Using Packet nodes for Internet nodes doesn't hold much appeal for me
either, although, there's nothing wrong with saving money!)

> While I can appreciate the BBS services of packet.  I have to question
> this as a main purpose in amateur radio. I'd like to see packet
> turn into a more real time "communications" avenue.  Logging into a
> mail box isn't really radio.

I disagree, Erich.  I think it's as much a part of radio as contesting,
dxing, experimenting - all those different modes.  Frankly, it seems to me
that traffic handling and bbs's are the thing for which packet is most
suited.  Voice communications seem to me to be far more efficient for real
time.  This based on holding a ticket for 40 years now and getting into just
about everything I could. :)

73,

Larry W1HJF

-----------------------------------------------------------------------------
L. M. Rappaport &  Associates, Inc.   rapp@lmr.mv.com   voice +1 603 237 8400
Colebrook, NH  03576-0158             CIS 72427,2567    fax   +1 603 237 8430

------------------------------

Date: 13 Jun 1994 12:58:32 GMT
From: ihnp4.ucsd.edu!usc!howland.reston.ans.net!gatech!concert!news-feed-1.peachnet.edu!news.duke.edu!godot.cc.duq.edu!codger!broderic@network.ucsd.edu
Subject: An open note to Gary Coffman, KE4ZV
To: ham-digital@ucsd.edu

Chris Mcmahon (packman@cix.compulink.co.uk) wrote:
: > I'm aware that TCP/IP is already available.  But this is a suite of
: > programs which operate only through packet, if I'm not mistaken. > 
: Ideally,any program which can run through standard TCP/IP should be able
: > to run through a packet-radio version of TCP/IP.  As far as I know, 
: this > is not currently the case.

: I've made the same comment to some of the TCP/IP fanatics in this area.  
: They seem to be happy with the various flavours of NOS/NET that exist.  
: I'd like to add some 'features' to NOS, but I get put off by having to 
: try and figure out what the impact of my changes will be on the 350 (ish) 
: source code files that comprise JNOS (for example).  What I'd ideally 
: like is a TCP/IP stack as a TSR that can have one or many hardware 
: drivers plugged into the bottom end and then present a standard API to 
: the programming world.  Then standard telnet, etc could be used on top of 
: the TSR and I could write software using the API without having to worry 
: about messing up any of the underlying code.  One possibility that could 
: be used, although I've not explored it, is some of the Winsock software.  
: Unfortunately that means learning to write sensible Windows programs :-(  
: I'm talking 'IBM PC world' here, but the same could easily apply to other 
: environments.
...... more deleted
: Chris - G6FCI Packet   : G6FCI @ GB7FCI.#16.GBR.EU
: Internet : packman@cix.compulink.co.uk

I was recently surprised to see references to ka9q code in a package
of Ftp Software's PC/TCP for dos.  This package comes with some 
winsock stuff (I think...), and although the source isn't available, one
might coax an ax25 packet driver into working with it.  I suspect that 
this is typical of many dos networking packages.

As far as other computing environments, work done for Sunos, and recently
Linux, points in this direction-- these provide kernel-layer interfaces
to the ax.25 world.  The chalenge now exists to write software to 
bridge between where packet users are today (mostly store/forward bbs
style systems) to something a bit more transparent.

Don Broderick N3GUZ

------------------------------

Date: Mon, 13 Jun 1994 15:06:26 GMT
From: ihnp4.ucsd.edu!usc!howland.reston.ans.net!europa.eng.gtefsd.com!emory!rsiatl!ke4zv!gary@network.ucsd.edu
Subject: An open note to Gary Coffman, KE4ZV
To: ham-digital@ucsd.edu

In article <X8XuNc7w165w@lmr.mv.com> rapp@lmr.mv.com (Larry Rappaport) writes:
>Erich Franz Stocker <stocker@spsosun.gsfc.nasa.gov> writes:
>> While I can appreciate the BBS services of packet.  I have to question
>> this as a main purpose in amateur radio. I'd like to see packet
>> turn into a more real time "communications" avenue.  Logging into a
>> mail box isn't really radio.
>
>I disagree, Erich.  I think it's as much a part of radio as contesting,
>dxing, experimenting - all those different modes.  Frankly, it seems to me
>that traffic handling and bbs's are the thing for which packet is most
>suited.  Voice communications seem to me to be far more efficient for real
>time.  This based on holding a ticket for 40 years now and getting into just
>about everything I could. :)

I agree with Larry, realtime "chat" mode is about the worst use for
packet. We have other modes that are much better suited to this type
of use. Packet is useful for the things it can do better than other
modes, and store and forward is a primary example of where packet
is superior to other modes. Packet does that well, but it isn't a 
substitute for a microphone when the need is for realtime person to
person communications. Hopefully, as the network speed increases,
realtime machine to machine communications will become an important
application facilitator, but right now non-realtime store and forward 
is the niche best served by packet.

Gary
-- 
Gary Coffman KE4ZV          |    You make it,     | gatech!wa4mei!ke4zv!gary
Destructive Testing Systems |    we break it.     | uunet!rsiatl!ke4zv!gary
534 Shannon Way             |    Guaranteed!      | emory!kd4nc!ke4zv!gary 
Lawrenceville, GA 30244     |                     | 

------------------------------

Date: 13 Jun 1994 12:31:10 -0700
From: mdisea!not-for-mail@uunet.uu.net
Subject: An open note to Gary Coffman, KE4ZV
To: ham-digital@ucsd.edu

In article <X8XuNc7w165w@lmr.mv.com>, Larry Rappaport <rapp@lmr.mv.com> wrote:

>suited.  Voice communications seem to me to be far more efficient for real
>time.

Maybe from the standpoint of the user but not from the standpoint of channel
usage. There's a reason the phone companies have gone digital /:) What we
ought to have is packet voice!

-=-=-=-=-=-=-=-=-=-=-=-=-==-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Hugh Shane                | 206 487 5909 (PST)
Motorola Wireless Data    | N7UAX 
shane@mdd.comm.mot.com    | #include <std_disclaimer.h>
-=-=-=-=-=-=-=-=-=-=-=-=-==-=-=-=-=-=-=-=-=-=-=-=-=-=-=-

------------------------------

Date: 13 Jun 1994 21:13:03 GMT
From: ihnp4.ucsd.edu!swrinde!gatech!newsxfer.itd.umich.edu!zip.eecs.umich.edu!yeshua.marcam.com!news.kei.com!ssd.intel.com!chnews!cmoore@network.ucsd.edu
Subject: An open note to Gary Coffman, KE4ZV
To: ham-digital@ucsd.edu

Hugh Shane (shane@mdd.comm.mot.com) wrote:

: There's a reason the phone companies have gone digital
: Hugh Shane                | 206 487 5909 (PST)

Hi Hugh, last time I checked, the initial deployment of IS-54 (digital)
was no more bandwidth efficient than NAMPS (analog). And GSM (digital)
is worse than NAMPS.

73, KG7BK, OOTC, CecilMoore@delphi.com

------------------------------

Date: 14 Jun 1994 00:36:33 GMT
From: koriel!newsworthy.West.Sun.COM!abyss.West.Sun.COM!spot!myers@ames.arpa
Subject: An open note to Gary Coffman, KE4ZV
To: ham-digital@ucsd.edu

In article 685@microsoft.com, davidar@microsoft.com (David Arnold) writes:

>However, there are going to be some who will not want to dedicate a PC
>to the problem.  The problem can be solved in software, but the software
>solution would only solve a particular platform configuration.
>For example, if someone were to write a AX.25 NDIS driver, that would
>solve the problem for a MS-DOS TCP/IP stack which support NDIS at the bottom,
>which, BTW, is probably very common.

Not a bad idea.  In the System V world, an AX.25 Streams module would be
cool, though a really good one would allow both AX.25 sessions and
other networking sessions, and would be a multiplexor module, not as
easy as a straight AX.25/IP module.  NDIS should be pretty straightforward,
though I have to write an NDIS driver.

>Can you imagine running PC Mosiac for an Amateur Radio WWW?

No.  Well, on second thought, I can.  It would suck.  Here's a :-) for those
who need it.

---
 * Dana H. Myers KK6JQ, DoD#: j	| Views expressed here are	*
 * (310) 348-6043 		| mine and do not necessarily	*
 * Dana.Myers@West.Sun.Com	| reflect those of my employer	*
 * This Extra supports the abolition of the 13 and 20 WPM tests *

------------------------------

Date: Mon, 13 Jun 1994 21:39:35 GMT
From: microsoft!wingnut!davidar@uunet.uu.net
Subject: Need info on Ottawa PI Card
To: ham-digital@ucsd.edu

Where can I get one, company contact names, etc.

Thanks.

davidar@microsoft.com
KD6IFY

------------------------------

Date: 14 Jun 1994 02:15:46 GMT
From: ihnp4.ucsd.edu!dog.ee.lbl.gov!agate!darkstar.UCSC.EDU!news.hal.COM!olivea!news.bu.edu!dartvax.dartmouth.edu!usenet@network.ucsd.edu
Subject: Packet Ideas Sought...
To: ham-digital@ucsd.edu

     I'm thinking this summer about what I might want to do for a
senior thesis in computer science next year, and I've decided that if
it is possible, I would like to do something involving packet radio. 
Im still trying to think of something to do, however.  I have a few
thoughts:
     The focus of whatever I do is probably going to revolve around the
nature of the amateur network as a fairly slow one (1200-9600 baud with
rare exception.)  It is also currently almost entirely accessed through
text based terminal programs.  There are a few specialty products on
the market, but these are all most entirely specialty terminal
programs. So, I could possibly explore something about the nature of
the interface used to access the services in the network.  I could
possibly explore the use of something like an X Window system or
similar open protocol for graphically-oriented distributed,
client-server programs.  
     Or I could possibly explore the netwrk for another angle, and ask
the question "what services should be provided and how can they be best
provided?"  "What sort of changes/enhancements in the network will be
the most beneficial to the user community?"  Is there something like
hypertext that will greatly improve the nature of the network?
     If you have any thoughts on this, I would appreciate it if you
would drop me a line, or start up a general discussion of it here.  I'm
just sort of collecting thoughts at this stage, so anything might help.
     Also, if anyone knows of a good source for technical documentation
on AX.25 or TCP/IP or the packet network in general, I would appreciate
the pointers.
     Thanks and 73's...
 
---
=======================================================================
Kenneth E. Harker  N1PVB        Dartmouth College  Amateur Packet Radio
kenneth.e.harker@dartmouth.edu  Hinman Box 1262    n1pvb@w1et.nh.usa.na
(603) 643-5716                  Hanover, NH 03755  or n1pvb-5 on 144.99
=======================================================================
             (PGP Public Key now available on request)

------------------------------

Date: 14 Jun 1994 08:55:09 GMT
From: ihnp4.ucsd.edu!swrinde!howland.reston.ans.net!xlink.net!scsing.switch.ch!swidir.switch.ch!univ-lyon1.fr!lanpc1.univ-lyon1.fr!cerdini@network.ucsd.edu
Subject: Thenet Eprom 1X for Thenet Node
To: ham-digital@ucsd.edu

 I'm looking for contents of Thenet Eprom 1X for Thenet Node (data which are
 loaded in TNC eprom)... Someone know where I can found that ?

--
Michel CERDINI - Universite Lyon 1      |  E-Mail cerdini@lan1.univ-lyon1.fr
Laboratoire d'Analyse Numerique URA 740 | Tel Pro 72 43 10 93 -     aka Djoe
43, boul. du 11 novembre 1918           | Minitel 78 36 19 96 (24h/24)     v
69622 Villeurbanne Cedex, France.       |  Modem  78 36 10 01 (V-Fast)   _/

------------------------------

Date: 13 Jun 1994 15:29:04 GMT
From: ihnp4.ucsd.edu!usc!nic-nac.CSU.net!charnel.ecst.csuchico.edu!olivea!ncd.com!newshost.ncd.com!hansen.ncd.com!phil@network.ucsd.edu
Subject: TM-733A and 9600 baud packet
To: ham-digital@ucsd.edu

I have a TM-733A and I would like to talk with others who are currently using
it for 9600 baud packet...

I would like to know what TXdelay you are running.  I seem to have to keep
TXDelay at 18... Which seems long.  Other than that... It seems to work
perfectly!

Phil
de kj6nn

------------------------------

Date: 13 Jun 1994 16:08:50 GMT
From: news.larc.nasa.gov!arbd0.larc.nasa.gov!zawodny@ames.arpa
Subject: TM-733A and 9600 baud packet
To: ham-digital@ucsd.edu

In article <2thu00$18f$1@rosebud.ncd.com> phil@hansen.ncd.com (Phil Graham) writes:
>I have a TM-733A and I would like to talk with others who are currently using
>it for 9600 baud packet...
>
>I would like to know what TXdelay you are running.  I seem to have to keep
>TXDelay at 18... Which seems long.  Other than that... It seems to work
>perfectly!
>

Wow!  I'd love to be able to set my TXDelay at 18 (180ms).  I currently have to
set it to 40 with my GE Custom MVP.  Anyone got any ideas how I can speed my
MVP up?  How about mods for 9600 buad?


-- 
 Joseph M. Zawodny   (KO4LW)                    NASA Langley Research Center
 Internet: zawodny@arbd0.larc.nasa.gov          MS-475, Hampton VA, 23681-0001
 Packet:   ko4lw@n4hog.va.usa

------------------------------

Date: 13 Jun 1994 20:59:15 GMT
From: usc!howland.reston.ans.net!gatech!newsxfer.itd.umich.edu!zip.eecs.umich.edu!yeshua.marcam.com!charnel.ecst.csuchico.edu!olivea!ncd.com!newshost.ncd.com!hansen.ncd.com!phil@ihnp4.ucsd.edu
Subject: TM-733A and 9600 baud packet
To: ham-digital@ucsd.edu

I thought that most 9600 baud folks were trying to run with a TX delay of 7 to
9 (aka 70 to 80 ms)...

How about it... What is common for 9600 baud?

phil
de kj6nn

In article <2ti0ai$f9p@reznor.larc.nasa.gov>, zawodny@arbd0.larc.nasa.gov (Joseph M Zawodny) writes:
|> In article <2thu00$18f$1@rosebud.ncd.com> phil@hansen.ncd.com (Phil Graham) writes:
|> >I have a TM-733A and I would like to talk with others who are currently using
|> >it for 9600 baud packet...
|> >
|> >I would like to know what TXdelay you are running.  I seem to have to keep
|> >TXDelay at 18... Which seems long.  Other than that... It seems to work
|> >perfectly!
|> >
|> 
|> Wow!  I'd love to be able to set my TXDelay at 18 (180ms).  I currently have to
|> set it to 40 with my GE Custom MVP.  Anyone got any ideas how I can speed my
|> MVP up?  How about mods for 9600 buad?

------------------------------

Date: Mon, 13 Jun 1994 15:09:52 GMT
From: world!dts@uunet.uu.net
To: ham-digital@ucsd.edu

References <2tf0kb$rql@eldborg.rhi.hi.is>, <1994Jun12.140915.1245@ke4zv.atl.ga.us>, <wb6wCrB332.H3o@netcom.com>dts
Subject : Re: info wanted: new Kantronics 9k6 modem

In article <wb6wCrB332.H3o@netcom.com> wb6w@netcom.com (Glenn Thomas) writes:
>Gary Coffman (gary@ke4zv.atl.ga.us) wrote:
>: In article <2tf0kb$rql@eldborg.rhi.hi.is> bnt@rhi.hi.is (Benedikt Sveinsson) writes:
>: >Hello.
>: >I was just hearing about the new Kantronics 9k6 packet
>: >modem. I saw the advertisment in QST, but no price or 
>: >free the MFJ from the packet only operation on my BBS.
>
>: The Kantronics 9600 baud modem is a G3RUH copy, like the MFJ
>: and the PacComm. The only difference is in form factor of the 
>: card to fit the different TNCs. Street price is in the range 
>: of $87-$109 at most shows. Aside from kludging the packaging,
>: your MFJ 9600 baud modem will work in the KAM.
>
>: Gary
>
>Actually, I don't think the KAM can do 9600 at all. I asked the Kantronics rep
>about the KAM and 9600 and was told that the KAM does its HDLC processing in
>software rather than the hardware implementation that the TAPR II and clones
>use. The software is fine for 1200 baud and slower, but just can't handle
>9600. The Kantronics data engine does work very well at 9600 and a G3RUH
>clone ought to work well in an TNC II clone.
>
>Oh...I understand that the KPC-3 also does HDLC in software, so it will never
>do 9600 either.

Kantronics has just announced a new box that handles one port for 9600 packet
and another for 1200 packet. The HDLC framing is in software. Keep in mind that
there is absolutely nothing wrong with using a software solution. It allows
a MUCH simpler method for providing fixes should a problem be found. Suppose
you find a bug in an HDLC-capable SCC chip? The usual answer to that is to
live with it...

I'm looking forward to trying one of the new Kantronics 9600 boxes...

Dan N1JEB

-- 
---------------------------------------------------------------
Daniel Senie                 Internet:     dts@world.std.com
Daniel Senie Consulting                    n1jeb@world.std.com
508-779-0439                 Compuserve:   74176,1347

------------------------------

Date: Mon, 13 Jun 1994 12:43:59 GMT
From: ihnp4.ucsd.edu!swrinde!emory!rsiatl!ke4zv!gary@network.ucsd.edu
To: ham-digital@ucsd.edu

References <2tf0kb$rql@eldborg.rhi.hi.is>, <1994Jun12.140915.1245@ke4zv.atl.ga.us>, <wb6wCrB332.H3o@netcom.com>
Reply-To : gary@ke4zv.atl.ga.us (Gary Coffman)
Subject : Re: info wanted: new Kantronics 9k6 modem

In article <wb6wCrB332.H3o@netcom.com> wb6w@netcom.com (Glenn Thomas) writes:
>
>Actually, I don't think the KAM can do 9600 at all. I asked the Kantronics rep
>about the KAM and 9600 and was told that the KAM does its HDLC processing in
>software rather than the hardware implementation that the TAPR II and clones
>use. The software is fine for 1200 baud and slower, but just can't handle
>9600. The Kantronics data engine does work very well at 9600 and a G3RUH
>clone ought to work well in an TNC II clone.
>
>Oh...I understand that the KPC-3 also does HDLC in software, so it will never
>do 9600 either.

Hmm. Good point Glenn. I used real TNC2 type TNCs when I was using
TNCs. I had forgotten that the Kantronics boxes are gutless wonders.
Still, I do know that the Kantronics 9600 baud modem that fits the
Data Engine (and the Gracillis PacketTwin) is a G3RUH clone, and will
work with MFJ and PacComm TNCs, though it's physically the wrong shape
to fit in the cases.

Gary
-- 
Gary Coffman KE4ZV          |    You make it,     | gatech!wa4mei!ke4zv!gary
Destructive Testing Systems |    we break it.     | uunet!rsiatl!ke4zv!gary
534 Shannon Way             |    Guaranteed!      | emory!kd4nc!ke4zv!gary 
Lawrenceville, GA 30244     |                     | 

------------------------------

End of Ham-Digital Digest V94 #194
******************************
